the language here is not good due to the same issue elsewhere: a single target acqf is perfectly fine eg for a desirability objective (ie multiple targets), whats really the problem is the number of outputs (and not targets)

detached comment 3: working with Pareto I think the Campaign.posterior call is much more important and probaly part fo the workflow (to check the target predictions and possibly make a subchoice of poitns to evaluate on the predicted frontier). Imo this then should be mentioned both in the UG and in the example (albeit briefy, jsut referencing the posterior method and explaiing why its useful for that)

Followup: for the API as well as less experienced users, it might be useful to have a posterior method or any other convenience object that returns a dataframe with targets, mean and var of posterior prediction, and not a posterior object

I was expecting a supports_multi_target=True in this class but perhaps its not needed or you had other reasons?

Yesterday I answered "yes, thanks, forgot" but I just realize that I omitted it on purpose since actually not needed / fulfills no purpose here. The potential confusion is: note that the two composite classes are not subclasses of Surrogate (which is where the flag is declared), they only implement the Protocol. Because the flag is only used inside Surrogate, there is no benefit of also exposing a copy of it in the composite ones – they will at some point dispatch the the actual surrogates, which is where the check is then performed (and if coming via this route, it will not even be required since the number of encountered targets is then trivially 1). So it's only ever needed if you don't go via the composite surrogates. Makes sense? If yes, please resolve

I just thought having such flag available outside of Surrogate could be useful, think eg about tests

can we mix target types in this example? ie one max and one min
reason: its safer to test mixed targets as both cases for the multiplier are contained

for a newbie otherwise its probably not clear why the objective is even called Pareto

is there any merit to deriving BroadcastingSurrogate from CompositeSurrogate?
It seems like a special case to me

No, inheritance does not help here – the attribute layout and way of calling the initializer is different. But I know what you had in mind: a BroadcastingSurrogate indeed behaves like a CompositeSurrogate with a flexible collection of single-task surrogates. So what you probably meant – and what indeed work – is to compose the CompositeSurrogate in that case via an alternative construction route:

@classmethod
def from_template(cls, surrogate: SurrogateProtocol) -> CompositeSurrogate:
    return cls(defaultdict(lambda: deepcopy(surrogate)))

With that, doing a BroadcastingSurrogate(template) would be identical to CompositeSurrogate.from_template(template).

In fact:

• the amount of code required would be significantly less (i.e. one entire class dropped)
• everything should still work via the API since we have our clever constructor flag
• we could still use the auto-conversion for single-target surrogates

But the consequence is that the creation step would no longer be a regular "class call" but requires this separate route instead. So which do we prefer?

but storing a sequence of n models (which is what qualitativly Composite does) is just the more general case of creating such a sequence but populating it with n deepcopies of the same model (which is what Broadcasting does qualitatively). Moreover, look at the fit methods, they are largely identical. These similarities to me suggest that we at least should not have 2 fully independent classes here...

I think this could be solved via inheriting the special case from the general case, or having a common intermediate class or your proposed solution. The latter is probably the most lightweight and I would support this too.

We should still pair this with a converter that allows this simple use case: I create a Pareto objective but pass only a single-target model (no broadcasting, no wrapping, no other class used). Then we kind of have best of both worlds?

And can we anywhere integrate the fact that these then are fully independent models? I think this is important to distinguish it from the hirarchical variant.

not mentioned anywhere in the surrogate userguide so far, but I think these are important explanations.

Im not calling for a complete revamp, but at least mention that the models currently mentioned are all single-output (with the exception of GP where it uses the builtin botorch mechanism)

and then mention the current ways of creating multi-output models via composite or broadcastin from the above

long term (not for this PR) I can imagine a section explaining (perhaps even with some flow charts) the four multi-output possibilities

1. botorch builtin broadcasting (comp efficient, no partial measurements)
2. broadcasting a single-target model, supports partial measurements
3. composite, supports partial targets
4. an inherently multi-output model not consisting of any independent models

do I understand it right that after this PR we already have possibilities 1 to 3 (without the partial targets of course)